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ABSTRACT 


On March 23, 1983, then-President Ronald Reagan 
challenged a group of engineers and scientists to make nuclear 
weapons "impotent and obsolete." This challenge led to the 
beginning of a new era in space technology and strategic 
defense, thus creating the Strategic Defense Initiative (SDI), 
better known as “Star Wars." By 1984, several studies had 
begun to show that software in conjunction with Battle 
Management/Command, Control, and Communications techniques 
would play a major role in determining the effectiveness of 
the SDI. The results from these studies caused numerous 
controversial debates on the reliability, dependability, and 
trustworthiness of the software. This thesis provides a 
framework for understanding the complexities of the SDI 
software and points out some of the major issues involved in 
the software debates. The structure for this thesis is based 
on presenting the opinions of various computer scientists and 
engineers, indicating the issues that are controversial and 
those that have been defined as a necessity for the SDI 
program. One of the major highlights is the SCI summary chart 
that provides the reader with a very brief narrative of each 
individuals’ opinion on the software issues discussed in this 


thesis. 
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I. INTRODUCTION 


Computer technology has advanced very rapidly since the 
late 1970s. In particular, computer hardware has allowed 
engineers to develop smaller, faster machines for more 
advanced computing power. In contrast, computer software has 
lagged behind in advanced technology. Software development is 
one of the major keys to the success of a Ballistic Missile 
Defense (BMD) system. Consequently, the Strategic Defense 
Initiative Organization (SDIO) has been tasked with finding 
ways to explore new software engineering techniques. These new 
developments will enhance U.S. chances of protecting itself 
from nuclear destruction. 

The purpose of this thesis is to analyze the SDI software 
debates that began in 1985 and continue even today. This 
thesis will, therefore, provide a framework which will allow 
individual readers to understand the complexity of the SDI 
software problem. Many computer scientists have put forth a 
variety of opinions, but these ideas and opinions have never 
been compared so that interested personnel from academia, the 
military, and industry would have an understanding of the SDI 
software and its complexities. 

In the early 1950s nuclear armed ballistic missiles 


represented an advance in weapon delivery technology. During 








that time the United States was vulnerable to missile attack. 
To counter these missile attacks, many anti- ballistic 
concepts were conceived; in particular, the SAFEGUARD 
ballistic missile defense system. It was developed in the mid 
1970s to serve as the answer to the Soviet Unions’ nuclear 
threat. Further analysis showed that (1) multiple, independent 
target warheads from a single booster could saturate defenses, 
and (2) our ballistic missile inventory proved inadequate 
against a superior Soviet force. [Ref. 1] 

SAFEGUARD was later disbanded and the Soviet threat is 
still ever present. The Strategic Arms Limitation Treaties 
(SALT) provided a linited reduction in the arsenals of both 
the United States and the Soviet Union. 

The concept of ballistic missile defense found a new spark 
in the 1980s under the Reagan administration. In March 1983, 
President Ronald Reagan tasked scientists to free us from the 
fear of nuclear weapons by making them “impotent and 
obsolete." This new outlook on strategic defense became known 
as the Strategic Defense Initiative (SDI) or "Star Wars." What 
is SDI? According to President Reagan, SDI is the development 
of an array of satellites carrying sensors, weapons, and 
computers to detect ICBMs and intercept them before they can 
do much damage [Ref. 2:p. 2}. The purpose of this concept was 


made clear in 1985 when the president stated: 


[SDI’s} purpose is to identify ways to exploit recent 
advances in ballistic missile defense technologies that 
have potential for strengthening deterrence and therefore 











increasing our security and that of our allies. [Ref. 2: 
Pp. 2) 


The Strategic Defense Initiative Organization (SDIO) is 
planning a three part phased development for ballistic missiie 
defense. Each phase builds incrementally on the previous, 
capitalizing on the benefits of the preceding phase. The SDIO 
and their contractors have studied several options for the 
first phase. The basic purpose of this phase would be to 
compel Soviet operational adjustments and compromises, thus 
reducing the confidence of Soviet planners. The second phase 
would enhance deterrence by imposing uncertainty on the Soviet 
strategic attack plans. A follow-on section of this phase 
would deny the Soviets’ the ability to destroy “militarily 
significant" targets (e.g., Missile Siios and Command and 
Control Centers). The third phase would be aimed at dominating 
the threat posed by nuclear ballistic missiles. That phase 
would be completed either by the Soviets choosing to rid 
themselves of obsolescent missiles by negotiating arms 
reduction or by engaging in an offensive-defensive arms race 
that could prove costly and leave both the Soviets and the 
U.S. financially handicapped. Figure 1.1 gives an overview of 


the phase I architecture for SDI. This architecture shows the 


different surveillance and tracking systems, radars, and 


interceptors that would be used from boost phase to terminal 
phase. Table I gives a description of the functions of the 


system elements in the phase I architecture. The reader should 














note that there is no description of the brilliant pebbles 
function, which replaces the Space Based Interceptor and is a 
very recent innovative, space kinetic energy concept. [Ref. 
3:pp. 2-6] 

Many supporters of SDI are very optimistic concerning the 
technologies used to deter Soviet Aggression. Although many 
areas lack confidence, scientists feel the 1990s brings 


promise of the reality of an SDI deployment. 
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TABLE I. 


Elements of Initial System 


SYSTEM ELEMENTS PRIMARY FUNCTIONS 





Boost Survelilance and Tracking * Detection of missile launches 
System (BSTS) * Acquisition and tracking of boosters 
* Booster kill assessment 
Space-Based Survelllance and * Acquisition and tracking of post-boost vehicles and 
Tracking System (SSTS) teentry vehicle clusters, ASATs, and sateffites 
* Kill assessment 
Ground- Base > Surveillance and * Closely spaced object resolution 
Tracking System (GSTS) * Tracking of reentry vehicles and penetration alds 


* Discrimination of reentry vehicles from penetration aids 
* KH assessment 


Ground-Based Radar (GBR)° e *, quisition and tracking 
* Discrimination of reentry vehicles from penetration aids 


Ground- Based (Exoatmosphertc) * Dest uction of reentry vehicles in late midcourse 
Interceptor (GBI) 


Space-Based Intercap.or (SBI) * Destruction of boosters, post-boost vehicles, and ASATs 
* Destruction of reentry vehictes in early midcourse 


Command Center (CC) * Human decisionmaking 

* Communications 

* Battle plan execution 

* Guidance for system operation and integration functions 
(SOIF) 





* GBR is currently under consideration for inclusion in Phase I. 





II. MAGNITUDE OF THE SDI SOFTWARE PROBLEM 


A. INTRODUCTION 

The focus of this chapter is on some of the major software 
issues that directly affect the success of SDI. The main issue 
that is unique to SDI is its physical size. According to the 
Office of Technology Assessment (OTA), the software required 
for the SDI program far exceeds that of any of its 
predecessors. Other factors discussed in this chapter are the 
use of software development tools and software engineering 
practices. Finally, design and testing efforts are discussed 


in relation to the simulation methods for SDI. 


B. NATURE OF THE BALLISTIC MISSILE DEFENSE SYSTEM (BDM) 

In the massive conglomeration of satellites, weapons, and 
sensors required for a strategic defense system lies what many 
supporters of SDI call the catalyst of the entire system. That 
catalyst is the software necessary to integrate the sensors 
and weapons. The SDI software problem is difficult because of 
the many compiexities involved. They include areas such as 
Simulation and testing, computer architectures, reliability, 
Maintainability, compatibility and interoperability, to name 


a few. 

















Gne reason for the confusion over software design and 
development stemmed from the alternate interpretations of 
President Reagans’ famous "Star Wars" speech. Based on the 
interpretation of Dr. David Parnas, former member of the 
Eastport Study Group, the only way to make nuclear weapons 
impotent and obsolete will be to eliminate the nuclear 
arsenals of both the United States and the U.S.S.R. The 
Eastport Study group, chaired by Pr. Danny Cohen, share an 
alternate interpretation. Dr. Cohen believes that any goals 
reached toward ultimate ballistic missile defense will be a 
major accomplishment. Views of Dr. Parnas and Dr. Cohen will 
be discussed more in Chapters III and IV. 

What makes the software such an integral part of the 
ballistic missile defense system? The main reason is that 
computer technology hardware and software must be adequate to 
control individual weapons and sensors and coordinate their 
operation. Battle Management and Command and Control (C2) are 
the two most important factors for SDIs’ success. The C2 
system must receive and act on information pertaining to 
thousands of missile launches, tens of thousands of warheads, 
and hundreds of thousands of decoys. To complicate matters, 
all this coordination must be done within the time it takes 
Soviet Intercontinental Ballistic Missiles (ICBM) to travel 
from their launch sites to U.S. targets. This time is 
estimated to be about 30 minutes. Therefore, any human 


intervention to correct errors will be minimal. [Ref. 4:p. 46] 














Managing an enhanced defense against ballistic missiles 
presents problems of unprecedented complexity. In 1983, the 
Defense Technology Study Team (DTST) examined the technologies 
needed for ballistic defense. The study, better known as the 
Fletcher Study, concluded that the development of software for 
a battle management system will be a task that exceeds in 
complexity and difficulty any that has been accomplished in 
the protection of civil or military war systems. The estimate 
for written software instruction at that time was 10 million 
lines. According to some analyst, that figure has more that 
quadrupled, exceeding 40 million lines of executable code. 


PReft, S:p. 174 


C. SIMULATION: DESIGN AND TESTING 

One of the many questions that analysts in the space 
program are asking is "How can the system be tested" or "When 
is the system operating correctly." Without a doubt SDI 
software developers are asking some of the same questions. 
Because of its complexity, the BMD system has to be tested 
from the research phase to the deployment phase. On a broad 
basis, testing should occur at four levels They include 
research, component and subsystem testing, system level 
testing, and deployed hardware and software testing. Research 
is literally nothing more than achieving an understanding of 
the process involved. Component and subsystem tests provide 


designers with a sense of validation or lack of validity for 








a given approach to a system or subsystem. System level 
testing is done to get rid of operational bugs and measure 
system performance against its specifications and its 
operational requirements. Finally, deployed hardware and 
software testing brings a realistic environment into focus. 
[Ref. 6:p. 1605] 

The Strategic Defense System (SDS) will contain many 
algorithms performing functions for surveillance, tracking, 
discrimination, weapons assignment, weapons control and 
guidance, network routing and control, security-access 
control, system fault tolerance, and fail-safe mechanisms. 
These algorithms are crucial to the identification and 
assessment of missile threats and the performance of sensors 
and weapons. This requires testing to be done on and end-to- 
end basis using the actual software code instead of an 
emulated version. The algorithms must be tested to find out 
how well the chain is functioning (i.e., tracing action from 
threat to sensor detection and track association to track 
correlation to track prediction. ...). There is obviously no 
one solution to the “testing problem, but scientists are 
measuring system performance through simulation. But, the 
simulation capability must be credible. Credibility is 
established when acceptable testing results are provided to 
those testing the system. SDIO recognized this need and 
organized the National Test Bed (NTB) in 1988. The author will 


discuss the NTB in more detail in Chapter IV. 


10 














According to the Eastport Study Group, simulation 
facilities must have the capability of modeling the components 
of the SDS, and its potential threats to answer questions like 
“Are the battle management strategies embedded in the BM/C3 
software adequate to cope with possible/potential attacks?" 
The simulation technique utilized to replace simulated 
hardware or software functions is known as “In-line" testing. 
With this technique engineering developments are accelerated 
by allowing the insertion of system components and prototypes 
into a realistic environment, thus detecting problems much 


earlier that with traditional methods. [Ref. 2:p. 29] 


D. SOFTWARE DEVELOPMENT PHASES 

The development of a comprehensive defense system depends 
very heavily on the software controlling it. If the software 
is faulty, it is inevitable that the system will fail. BMD 
software has four crucial areas that are critical factors in 
attaining the objectives for which the system is designed. 
These include: planning, design, implementation, testing and 
debugging. It should also be noted that these phases are not 
always sequential and some overlap will occur. 

The first crucial phase for developing SDI software is 
planning. Planning involves stating the necessary 
specifications and requirements to accomplish a mission. These 
elements must be bounded in some manner to give certain 


definition to the problem. The precise specification of what 


it 














the ballistic missile defense must do is a complicated task. 
For instance, if the mission is to shoot down Soviet missiles, 
knowing only Soviet missiles exist, then this problem is 
relatively simple. Unfortunately SDI will operate in a more 
complicated environment. For example, how can Soviet missiles 
be distinguished from non-Soviet missiles or what if a Soviet 
missile is headed for a target in East Germany? The developer 
will therefore try to predict every contingency in order to 
decide how the software should respond. A number of 
possibilities and circumstances may not be foreseeable, but 
the developer must somehow properly plan for these 
contingencies [Ref. 4:p. 48}. 

The design phase for SDI software development is a large 
task in its own right. In particular, the developers must 
implement the specifications and requirements defined in the 
first stage (planning) through the use of computers. This is 
where all the algorithms must be incorporated and sequences of 
action established. 

Based on the experiences of other major military systems, 
integration of individual components generates problems when 
the entire system must operate near its limit. For instance, 
during an exercise using the World Wide Military Command and 
Control System (WWMCCS), a communication network used by 
military and civilian authorities for message transaction to 
and from the field, the message transmission rate was 


satisfactory when the system was in routine operation. On the 


12 











contrary, when additional regional centers were connected to 
the WWMCCS, the system performance was degraded tremendously. 
(Ref. 4:p. 48] 

Simulation and testing is usually used to solve problems 
on a small basis, but they are limited with respect to large, 
interconnected systems such as the BMD system. Further 
discussion of this issue will occur in Chapter VI. 

The final phase involves debugging real time software. 
Debugging can account for almost 70 percent of the total life 
cycle cost of a software development project. lwo salient 
points that make software maintenance difficult are: 1) Errors 
don't reoccur easily, and 2) Errors found after a system 
becomes operational must be eliminated. To add even more 
complexity to this problem, analysts state that the 
probability of introducing an error while eliminating a known 
error ranges from 5 to 50 percent. [Ref. 4:p. 50] 

These four phases indicate that software development for a 
BMD system is critical. The author believes that scientists 
and engineers have a lot of ground to make up in terms of 
finding viable solutions to make the Reagan administrations’ 


prophecy a reality. 


E. ROLES OF SOFTWARE IN BMD 
Ballistic Missile Defenses can’t perform without computers, 
just as computers can’t perform without software. Software is 


nothing more that a set of sequential instructions used to 


13. 











direct the actions of computers. The software, because it is 
expected to perform continuously with or without failures, 
must be reliable and trustworthy. 

There are those who support or oppose the easibility of 
the development of the software based on their technical 
expertise. One unique requirement for SDI is that the software 
driving the BMD would have to work reliably the first time 
it’s used in battle. Dr. David Parnas wrote the following on 
software reliability: 

People familiar with both software engineering and 
older engineering disciplines observe that the state of 
the art in software is significantly behind that in other 
areas of engineering. When most engineering products have 
been completed, tested, and sold, it is reasonable to 
expect that product design is correct and that it will 
work reliably. With software products, it is usual to 
find that the software has major “bugs" and does not work 
reliably tor some users. These problems may persist for 
several versions and sometimes worsen as the software is 
“improved" [Ref. 7:p. 433] 

Some computer scientists and engineers believe that 
software development is advanced enough to make the SDI task 
tractable. Dr. Frederick P. Brooks, for example, stated: 

I see no reason why we could not build the kind of 
software system that SDI requires with the software 
engineering technology that we have today." [Ref. 8: p. 
284] 

There are several positions on the feasibility of SDI 
software development; therefore, it is important to understand 
these positions when analyzing the roles of software in BMD. 


According to an Office of Technology Assessment (OTA) 


report in 1988, software for BMD would be expected to: 




















1. Be the agent of system evaluation, permitting changes 
in system operation through reprogramming of existing 
computers. 


2. Perform most complex tasks in the system, such as 
battle management. 


3. Be responsible for recovery from failures, whether 
they are hardware or software failures. 


4. Respond to threats, both anticipated and unanticipated 
against the system. 


These roles or functions of software are just a few among 
many that software technology must contend with. Futhermore, 
BMD software would be more complex than any previously built. 
A conclusion from the Fletcher Study stated: 

Specifying, generating, testing, and maintaining the 
software for a battle management system will be a task 
that far exceeds in complexity and difficulty any that 
has yet been accomplished in the production of civil or 
military software systems. [Ref. 9:p. 4] 

In this author’s opinion, DoD has found that producing C3 
and information processing software for weapon systems is not 
an easy task. There are many similarities between a BMD and 
today’s typical C3 systems, such as weapons guidance, 
targeting, and real time communication control, but the 
differences are enormous. They include very little human 
intervention, much larger battle spaces to manage, operating 
in a nuclear environment, and many others. BMD software is 
critical to successfully defending the U.S. and its allies 


against any nuclear threats. Because of complexity and other 


software issues, it is very important that requirements be 
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stated specifically before the development of any software 


modules. 
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III. ANALYSIS OF THE SDI DEBATES: WHAT THEY DISAGREE ON 


A. INTRODUCTION 

This chapter describes the different views of some noted 
software engineers, professors, analysts, and computer 
scientists on the reliability issues concerning SDI software. 
The opinions are those of individuals with first hand 
knowledge and interest in the SDI program. Among them are: 
Dr. Danny Cohen, Chairmen of the former Eastport Study Group; 
Dr. Frederick Brooks, Professor of Computer Science at the 
University of North Carolina; Dr. David Parnas, Professor of 


Computing and Information Systems at the University of 


Victoria, B.C.; Dr. Solomon J. Bushbaum, Executive Vice 


President for Customer Systems at AT&T Bell Laboratories, and 
C.A. Zraket, President and CEO of the Mitre Corporation. 

The author will try to provide the reader with a framework 
for understanding some of the complexities associated with 
designing and developing reliable, trustworthy, error-free 


code. 


B. WHY SDI SOFTWARE MAY BE UNRELIABLE 
Defining reliability as it applies to SDI software is 
difficult because of the extreme demands on the system and the 


inability to operationally test those demands. The software 
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will be responsible for ensuring that the BM/C3 systems can 
bind together a system of worldwide sensors, weapons, 
platforms, and communication links. Knowing that a task of 
this magnitude must be completed in a matter of minutes, 
reliable software is important for a successful strategic 
defense. (Ref. 2:p. 1] 

In 1985, Dr. David Parnas resigned from the panel on 
computing in support of battle management known as_ the 
Eastport Study Group. He felt many of the computer science 
problems could not be solved prior to the development of an 
Anti-Ballistic Missile (ABM) system. Dr. Parnas later wrote 
eight articles that supported his resignation. Among the noted 
papers were; "Why software is unreliable," “Why the SDI 
Software System will be untrustworthy," and "The Limits of 
Software Engineering Methods." [Ref. 7:p. 2] 

Dr. Parnas does not apply the term reliability towards a 
strategic defense system as he does to other programs. Dr. 
Parnas appeared before the U.S. Senate Subcommittee on 
Strategic and Theater Nuclear Forces in December 1985. There 
he stated that reliable software could indeed be built if all 
the requirements are known and the software can _ be 
controllable as well as predictable. These factors can be 
determined for a system such as the telephone system, but they 
don’t apply well to SDI. First, tools such as mathematical 
analysis and exhaustive case analysis are useless in some 


sense because the requirements for the software functions are 
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controlled by strategies and tactics of the Russians. 
Secondly, redundancy, which is considered by some authorities 
to be the key to reliability, is very expensive in space. 
Redundancy is good for independent component failures, but 
design failures pose a bigger problem. For instance, if 
redundancy is implemented in a section of code that already 
contains a design flaw, we’ve given ourselves a “double 
whammy." These tools are great for mathematical analysis that 
work on continuous functions, but software is a discrete state 
system that cannot be described by these functions. [Ref. 8:p. 
286} 

Dr. C.A. Zraket, in his article on “Uncertainties in 
Building a Strategic Defense" stated that the feasibility of 
designing and building reliable s-ftware for a BMD system 
depended largely on (1) trustworthiness - known, predictable 
effectiveness, and freedom from "catastrophic flaw," (2) fault 
tolerance - ability to continue functioning coherently when 
part of the system is damaged, and (3) information security - 
ability to prevent programs from being exploited by using 
“trusted" programs and coding and authentication techniques. 
To sum up the problem of reliability, Dr. Zraket stated the 
following: 

Much more research and a lengthy development effort 
are needed in dealing with the operational design and 
implementation of a specific BMD architecture before a 


conclusive judgement can be made about the reiiability of 
software for this space-based system. [Ref. 6:p. 1605) 
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Everyone realizes that the SDI system is faced with 


reliability problems, but how reliable must the software be or 





as stated by Dr. Frederick Brooks, "How good is good enough?” 
For instance, if 10,000 nuclear missiles were fired at the 
United States and our system operated effectively at 99.9 
percent, 10 nuclear bombs would still bombard our country. Not 
good! Figure 3.1 gives the reader some idea of the number of 
errors created and later found and fixed (Rayleigh Curve). 
This curve is intended to be a rough representation of a 
subsystem for SDI. The curve was projected on the basis o¢ a 
real-time C2 system consisting of 1 million lines of source 
code. The x-axis represents the time in mosths while the y- 
axis represents the number of errors per month. There are 
several milestones that occur during the development and 
operation phases. The sequential stages are represented by the 
vertical lines and are defined as follows: 

1. Preliminary Design Review (PDR) 

2. Critical Design Review (CDR) 

3. First Code Complete 

4. System Integratiun Test 

5. User-operational Capability 

6. Initial Operational Capability 


7. Full Operational Capability (95 percent reliability 
level) 


8. 99 percent reliability level, and 


9. 99.9 percent reliability level. [Ref. 10:p. 63] 
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Due to the vast size and complexity of SDI, it would take 
approximately 7.5 years to reach the 99.9 percent reliability 
level. Figure 3.2 shows the total expected errors. Even at a 
99.9 percent reliability level there would still be over 6,000 
cumulative errors. (Keep in mind that this is the case for 1 
million lines of code.) [Ref. 10:p. 63] At the third annual 
IEEE Conference on Strategic Software, the number of lines of 
code to operate SDI was up to 20 millions lines, thus 
increasing the concern and need for reliable software systems. 


(Ref. 11) 
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SDI software may have a reliability problem, but the real 
question is how to evaluate the systems’ dependability. Other 
questions are what are the characteristics of a reliable 
system, and how much emphasis should be placed on each 
characteristic for evaluating the system? The Office of 
Technology Assessment (OTA) addressed these issues and labeled 


the following commonly considered characteristics: 


1. Correctness - whether or not the software satisfies 
its specification 


2. trustworthiness - probability that there are no errors 


in the software that will cause the system to fail 
catastrophically 
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3. Fault tolerance - either in prevention (i.e., 
capability of the software to prevent a failure 
despite the occurrence of an abnormal or undesired 
event - or failure of recovery 


4. Availability - probability that the system will be 
available for use 


5. Security ~ resistance of the software to unauthorized 
use, theft of data, and modifications of programs 


6. Error incidence - number of error in the software, 
normalized to some measure of size 


7. Safety - prevention of human life and property under 
specified operational conditions 


These characteristics are critical to system reliability. 
The process of instilling reliability into SDI software must 
begin at the software development phase. It is very difficult 
to “add in" reliability after the software design is complete. 
As stated earlier, this can lead to exponential cost increase. 
(Refs 12¢p.- 288] 

Even though there is a lack of ways of quantifying 
confidence in software, people trust computerized systems. For 
instance, no one thinks about the probability of a disastrous 
error occurring in the software of an automated teller 
machine. This attitude allows scientists to start the 
development of systems without having all of the reliability 
issues resolved. The more confidence that is gained in a 
system, the less the resistance that will be shown in 
accepting that system. There are a few entities that 
characterize dependable software systems. They include 1) 


extensive use and abuse of the system, 2) predictable 
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environments, 3) low cost of failures, and 4) stable 
requirements [Ref. 12:p. 235-236]. A strategic defense system 
exhibits none of h these entities. 

The extensive use of any system, whether it be an 
automobile or a computer system, may be the most important 
factor for building confidence in that system. This confidence 
comes from extensive use and abuse. Simulations cannot test 
extensive use and in many cases real world complications are 
expensive and poorly understood. The software for SDI falls 
within a similar category because it can only be tested end- 
end during an actual battle. [Ref. 12:p. 45] In essence the 
first time may be the only time. Dr. Solomon Bushbaum believes 
that most, if not all, of the essential attributes of the 
BM/C3 systems have been demonstrated in comparable terrestrial 
systems, namely, the U.S. Public Telecommunications Network. 
(Ref. 8:p. 275] Although the telephone system has been 
extensively “used and abused," it is not a weapon system. 
Figure 3.3 shows a comparison of the characteristics for 
SAFEGUARD, SDI, and the phone system with respect to 
dependability. In a letter to Congress from designers and 
maintainers at AT&T Bell Labs, they stated: 

"Despite rigorous test, the first time new equipment is 

incorporated into the telephone network, it rarely 
performs reliably. [Ref. 12:p. 243] 

If the behavior of the software can be predicted in an 

operational environment confidence can be gained because the 


environmental factors are known. This is the case with the 
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Characteristics of Dependable Systems 











Applied to 
SDI, SAFEGUARD, AND THE TELEPHONE SYSTEM 
Characteristic : SDI SAFEGUARD pe lavaeg 
Extensively used & abused..... NO No Yes 
Yes 

Predictable environment......... No ne 
Low cost of a failure... No No Yes 
Stable requirements................. No Yes mgs 
Well-understood 
PFEDECESSOF .ooecccscsecsssssecssssesssssees No Yes Yes 
Simple deSigN.........sceccccecse UKN ? Yes 
Disciplined development... UKN Yes Yes 
Source: OTA 

Figure 3.3 


telephone system where mathematical models can be used to 
measure the amount of traffic on a switching circuit. On the 
contrary, in a BMD environment, nuclear background and 
countermeasures will not be predictable prior to the battle. 
[Ref. 8:p. 345] Therefore, one’s confidence in a system may 
be lessened by the unknown factors. 

All software systems inevitably experience software 
failures. Users lack confidence in these systems if the risk 
associated with gaining information is more than that of 
losing it. In the case of the phone system, the ability to 


recover from a failure at a low cost increases the users 
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willingness to use the system more. Besides, no major war will 
be won or lost because a phone call cannot be recovered or 
reconnected. On the contrary, software for BMD systems must be 
reliable. There will be no time to renair errors during a 
battle. If the error is “catastrophic," many thousands of 
warheads will reach their targets. According to an OTA report 
concerning technology for preventing catastrophic failure, the 
following statement was made: 

OTA found no evidence that the software engineering 
technology foreseeable in the near future would make 
large improvements in the dependability of software for 
BMD systems. In particular there would be no way to 
ensure that BMD software would not fail catastrophically 
when first used. [Ref. 12:p. 246] 

Finally, defining all the requirements is not feasible, 
mainly because the threats, the strategies, countermeasures, 
and technologies are in a constant evolution. In preparation 
for writing this thesis, most software analysts and engineers 
when asked “What is the toughest problem facing SDI software 
development," the majority stated: changing requirements. This 
is not a new issue. The problem has plagued some of our other 
major weapon systems, in particular the B-1 bomber program. 
Many changes were incorporated during the development stage 
which resulted in major deficiencies. According to a report on 
the B-1 bomber: 

Defense officials blame many of the program’s problems 
on the decision to begin producing the aircraft at the 
same time that research and development efforts were 
underway, forcing engineers to experiment with some 


systems before they were completely developed. [Ref: 13: 
p. Al} 
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Stability in software has a special importance because of 
the many decisions involved in the design. The earlier a 
decision is made, the harder it is to correct later in the 
process. The author believes that the key is to have iittle 
change during the development process. This process increases 
the confidence in the system and keeps cost at a minimum. 

The previous discussion dealt with issues that were deemed 
necessary for reliable software systems. Whether or not 
technology is able to accomplish this feat is another 
question. Supporters of the SDI program lean towards the 
answers from the Eastport Study Group and various other 
reports that have been submitted to Congress. Dr. Yale J. 
Lubkin, director of advance technology for a major EW 
manufacturing company, compared reliability of software 
systems to that of the human brain. Dr. Lubkin stated that the 
brain is a discrete state system that works with continuous 
state components to produce complex sensor/logic systems. He 
also stated that these systems work well on a scale such as an 
“inchworm." For example, as the worm rotates its sensor, 
searching to define the safe boundaries of its domain, it can 
learn to proceed rapidly on a safe path without reaching a 
boundary of discontinuity. Therefore, he concludes that the 
implication that software systems will always be unreliable is 
not true. It is obvious that these debates have very valid 
positions on both sides. The winner may not be determined 


until the battle is over. [Ref. 28:p. 12] 
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C. DEFINING TRUSTWORTHY: THE PARNAS VIEWPOINT 


In the previous section reliability was discussed as a 
measure of system behavior. As discussed earlier, reliability 
is traditionally measured as the mean time between failure 
(MTBF). Trustworthiness and reliability are generally 
considered by most as almost being the same. It is obvious 
that reliability has been quantified but not many attempts 
have been make to quantify trustworthiness. According to the 
OTA, two possible reasons for the lack of interest in 
quantifying trustworthiness may be 1) trust is determined 
qualitatively as much as quantitatively and 2) most systems in 
critical applications are guarded by human operators. Whether 
these reason are true or not, the term trustworthy must be 
defined. [Ref. 12:p. 232) 

As noted earlier Dr. David Parnas resigned from the 
Eastport Study Group because of his inability to perceive that 
software for the SDI program would be trustworthy. After his 
resignation, Dr. Parnas wrote several papers about SDI 
software issues. Of particular interest was the article on 
“Why the SDI Software System Will Be Untrustworthy." That 
article described the characteristics of the proposed battle 
management software system and provided implications of the 
problem characteristics. Dr. Parnas also stated reasons for 
not trusting the software before the U.S. Senate Subcommittee 
in 1985. The rest of this section will focus on the "Parnas 


Viewpoint" of why software systems are not trustworthy. 
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Common definitions of trust include the belief that 


conditions are favorable so that failure does not occur and 
the belief in one’s ability to maintain confidence. This 
definition seems to fit very well with Dr. Parnas’ reasons why 
the software would not work correctly when really needed. Two 
basic reasons are 1) we do not know exactly what the software 
is supposed to do, and 2) we must somehow validate the fact 
that it operates the way we think it should operate [Ref. 8:p. 
290). These reasons lead Dr. Parnas to believe that the 
software could not be trusted because it is not known whether 
the software will be correct or not. Scientists and engineers 
agree that the software will not be perfect. Everyone involved 
with the SDI program is willing to accept that fact. The 
_ problem is how to stop the system from failing 
catastrophically. Relating back to Dr. Frederick Brooks’ 
question of “How good is good enough," Dr. Parnas responded in 
a letter to the editor of IEEE Computer magazine. He stated: 
I think that the answer is clear. To be good enough we 
have to know, with high confidence, how good it is. To be 
good enough, we must know that the system will not fail 
catastrophically. [Ref. 14:p. 6] 

In the previous section, the author described some of the 
characteristics that reliable software systems should have. 
From this viewpoint requirements of the battle management 
software and some of the implications of these characteristics 


will be discussed. The following is a brief explanation of 


each: 
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Identification, tracking and weapon targeting are 
required system functions whose ballistic 
characteristics cannot be known with certainty prior 
to the battle. The implication of this problem is that 
fire control software cannot be written without making 
assumptions about the enemy’s weapons and targets. 
Therefore, if the system is developed without 
knowledge of these characteristics, there are likely 
to be fatal errors in the software. 


Determining the behavior of computers within the 
network cannot be predicted because of countermeasures 
by an attacker. This leads to the belief that the 
component availability and throughput of the system 
will also be inhibited. There are some systems where 
the likelihood of failures can be predicted from past 
history or component failures are unlikely and 
statistically independent, but this does not hold true 
for the required battle management software. 


Real time testing of the software will be impossible. 
Although operational software for military aircraft 
undergoes rigorous ground and flight testing, "bugs" 
can and do show up in battle conditions. With this 
inability to test the system under real-time field 
conditions, the confidence and faith in the system is 
minimal. 


There will be little possibility of human intervention 
during a nuclear war. This means that debugging and 
modifications of the program during a_ short period 
are not very likely to occur. Software modifications 
have been made in the field during previous wars 
(programming notes on the walls of trucks carrying 
computers; Vietnam). Some systems have even become 
reliable through such techniques, but the likelihood 
of these events occurring in a 30 minute war is 
extinct. 


The number of targets detected and identified will 
determine the computational requirements of each 
process. The problem here, as in other cases, is that 
the number of targets or decoys cannot be predicted. 
Theoretically, this can be done using runtime/pre- 
runtime scheduling techniques. This scenario would 
work only if a worse case real-time schedule could be 
worked out in advance. 


Each weapon system will include its own weapons and 


sensors which will require complex software systems to 
run them. To make matters worse, these systems will be 
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dynamic during and after development. With a large 

number of contractors involved, the components will be 

subject to independent system modification. It is a 

known fact that as the size of software projects 

increase, the level of difficulty involved in terms of 
integration increases. When interfaces are changed, 

the problem is worsened. [Ref. 15] 

The views shared by Dr. Parnas do not indicate that 
software cannot function effectively. They only point to the 
issues that engineers must consider before launching into a 
massive space project like SDI. In an article in Technology 
Review entitled “The Software for Star Wars: An Achilles 
Heel?" Herbert Lin discussed the "can do" spirit of Americans 
to overcome any so-called impossible feat. He stated that it 
is fashionable for proponents of SDI to dismiss claims of 
impossibility by citing lessons from history. The fact that 
someone said something is impossible does not make it 
possible. In his closing argument he states: 

No one can know with certainty how the BMD software 
would work during a large scale attack. How much 
confidence should the American public have in a BMD 
system so complex that no one person can understand it? 
That cannot be certified as error-free? That it is 
operationally untestable? The lessons learned from the 
performance of other large software systems suggest that 


the answer might be “very little" confidence indeed.” 
(Ref. S5:p. 18] 


D. VIEWS OF WHY SDI SOFTWARE WILL NOT BE ERROR-FREE 

The hazards of error-prone software has become common a 
part of life on a daily basis. Whether it be a miscalculation 
on our phone bills, lost airline reservations, or an 


additional deposit to our checking account, errors are found 
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that may or may not alter our life styles. In many situations, 


the magnitude of the error is small and the recovery process 
is trivial. Unfortunately this is not always the case, 
especially with the SDI software. In the previous sections of 
this thesis the requirements for a BMD software system were 
stated. Errors will inevitably occur, but they must be kept to 
a minimum. [Ref. 10:p. 62] 

Ware Myers discussed the problems of errors in large, 
complicated software systems. He stated that they are created 
in the process of formulating requirements, writing 
enecifications, designing software, and writing code. Most 
analysts try to "spot check" the code by using techniques such 
as design reviews, module testing, and integration testing. 
Many errors occur when reprogramming is done to remove the 
errors found earlier. The fact is, there is no certainty that 
all errors in large complex software systems can be found and 
fixed. [Ref. 10:p. 62] 

Dr. Solomon Bushbaum tried to silence many critics on the 
issue of error-free software by rephrasing the question to ask 
whether or not the total BM/C3 system could be designed to be 
robust and resilient in an error-prone environment. As alluded 
to earlier, Dr. Bushbaum is referring to the U.S. Public 
Telecommunications Network. [Ref. 8:p. 274] The author 
believes that the phone system is reliable, available, and 


adaptable because it has been “used and abused" continuously 
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for years. These are not exactly the characteristics thar 
relate to the BMD software systems. 

There are no technological breakthroughs that will make it 
possible to write error free software. It has not happened in 
the past and the state-of-the-art tools and techniques for the 
future are not promising. According to the Eastport Study 
Group, the focus should be on developing software that will 
function dependably despite the presence of errors. [Ref. 2:p. 
2} This means placing more emphasis on the software research 
that the SDIO supports and finding ways to reduce errors. 
About 80 percent of errors found in large real-time systems 
are said to be caused by faulty requirements and design flaws. 
Some software professionals think that by using proper 
development methodologies, intensive testing, formal 
validation techniques and fault tolerant designs, we can 
reduce the incidence of errors. The process involves using 
computer aids and analysis procedures to test smaller 
components of large systems. This results is trying to 
narrowly predict and reduce the number of errors in a program. 
Fault tolerant design techniques employ methods such as 
multiversion development. In this process, two separate teams 
of programmers are given the same set of requirements to 
develop programs. The programs are then compared to each other 
to reduce common mode errors. [Ref. 10:p. 65} 

Although the ultimate goal is to design and develop a 


software system that operates effectively with some known 
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errors, some scientists and engineers believe that the process 
of counting errors is not well understood. [Ref. 10:p. 65] It 
iS quite obvious that, in most cases, quantitative arguments 
are more convincing than qualitative ones. People are more 
comfortable with numbers that support an argument. In a letter 
to the editor of Compu=er magazine, Dr Parnas stated: 

Error statistics make excellent diversions but they do 
not matter. A low error rate does not matter. A low error 
rate does not mean that the system will be effective. All 
that does matter is whether the software works acceptably 
when first used by the customers; the sad answer is that, 
even in cases much simpler that SDI, it does not. What 
also matters is whether we can find all the "serious" 
errors before we put the software into use. The sad 
answer is that we cannot." (Ref. 14:pp. 6-7] 

One cannot totally believe that the debate on whether SDI 
software can be error free hinges only on assumptions about 
error incidence. The number of errors found per thousand lines 
of code cannot measure program correctness. The fact remains 
that all of today’s large computer systems contain 
undiscovered flaws that are revealed only after the systems 
are put to use. [Ref. 24:p. 94] Even during program 
development, the "bugs" (errors) began to appear. The simplest 
type of error, such as typographical slips, sometimes cause 
the largest conseq:ences. One of the most infamous examples is 
the failure of the Mariner I Probe to Venus in 1962. In this 
case, a period was substituted for a comma in the FORTRAN 
language, consequently, the probe had to be destroyed shortly 
after launch (Ref. 24:p. 94}. Most fourth generation 


languages check for notation errors automatically but logic 
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errors are more difficult to prevent. Even with smali 
programming projects done at the Navel Postgraduate School, 
logic errors cost valuable computer resource time. 

Other errors are caused by a programmer’s lack of knowledge 
of certain types of contingencies. These errors cause major 
problems. There is no "physical" mistake to be found. The 
error is caused because the program branches are not 
available. Noted author, Alan Boring, gave an explanation that 
in large-scale programs there is usually nobody who 
understands the entire system completely. Humans play a major 
role in manufacturing errors. Programming errors are 
especially insidious because there is no way of indicating 
there is a problem prior to testing. Another problem is that 
if the section of code where the error lies is never executed, 
the error is never found. Unfortunately, one day that “special 
contingency" may occur and that section of software needs to 
execute properly, but does not. As stated earlier, redesigning 
software is expensive. The Department of Defense (DoD) will 
spend about 10 percent of the budget or $30 billion on 
software in FY90. With the recent lessening of the Soviet 
threat, it is not likely that Congress will dispense more 
money for redesigning systems that do not operate properly. 
{Ref. 16:p. 26] 

Zraket feels that because of the discontinuous and highly 
discrete nature of software, generating millions of lines of 


software code may cause small errors with a large operational 
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impact on the BMD system. The solution: rigorous design and 
testing. This solution will be discussed more in the next 
chapter. Zraket also stated that the most important and 
prevalent uncertainties and flaws occur in the operational 
design and structure of the software. His approach is similar 
to that of Myers; build the operational design and software 


in increments, evaluating each sequence. 
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IV. ANALYSIS OF THE SDI SOFTWARE DEBATE: WHAT THEY AGREE ON 


A. INTRODUCTION 

This chapter focuses on a few of the SDI software issues of 
which both supporters and critics have agreed. This is by no 
means an exhaustive list of requirements, rather it typifies 
issues that are less debatable. The reader should be informed 
that contrary to the style of the previous chapter, the views 
shared in the debates addressed in this chapter are those of 
a composite group and not necessarily those of individuals. 
Anyone who has studied the SDI software issues can testify 
that there are several other problems that have been heavily 
debated. The author will attempt to discuss the relative "show 
stoppers"; What would happen if these issues were not 
resolved? 

The major software issues that have survived the debates 
are 1) the need for a specific battle management\C3 
architecture, 2) the need for a dedicated national test 


facility, and 3) the need for a SDS software center. 


B. THE NEED FOR A SPECIFIC BATTLE MANAGEMENT/C3 ARCHITECTURE 
PRIOR TO DEVELOPMENT 
One can easily categorize the SDI as a vast system 


consisting only of thousands of sensors, weapons and 
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platforms. More than likely, it is often overlooked or taken 
for granted that software, computers, and communications drive 
the entire system. The Eastport Study Group suggested that too 
much emphasis was being placed on weapons and sensors and not 
nearly enough on the software complexities concerned with the 
design and development. The Eastport study concluded that the 
choice of system architecture depends on the feasibility of 
the battle management software that can be simulated, tested, 
and maintained. Given these facts, one must consider the 
factors that serve as criteria to evaluate the architectures. 
Fundamentally, performance, testability, and cost are a few of 
the criteria considered. For each of these criteria, measures 
of performances (MOPs) must be defined. For performance, the 
measures of performance are linked to the survivability or the 
robustness of the system. These factors go hand-in-hand with 
reliability and durability, necessities for real world 
performance. An MOP for testability must be structured from 
the results of small-scale tests. Reasoning for that approach 
is based on the mere fact that full-scale tests are 
impossible. The cost of building, deploying, and maintaining 
a strategic defense system will be inherently high. [Ref. 2:p. 
22) 

The SDIO realized that battle management software and its 
supporting C3 elements must be given the highest technical 
priority. The task set before them was to find an architecture 


that implements human control, lowers cost, and reduces the 
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magnitude of required coordination and communication control. 
Although these factors were heavily debated, the SDIO 
considered them a necessity. What type of system architecture 
would best satisfy these issues - centralized, decentralized, 
or layered. Viewing the software as a battle manager, there 
were many questions about the type of structure needed. 

A centralized architecture required the software to provide 
information to every element (sensors and weapons) in the 
network instantaneously and simultaneously. This process would 
make fault tolerance and error recovery virtually impossible. 
Also, human control would have no intercession within the 
process. Computing resources for a centralized system are 
focused in one location and may consist of several processors 
that share common memory devices. These systems are called 
multi-processors. The processors have a high rate of 
communication because of high data rates, resulting in a 
tightly coupled system. Figure 4.1 shows a "centralized" 
representation of the architecture. Additionally, the 
centralized architecture would not allow simulated full-scale 
testing, a major criteria for SDI’s acceptance. (Ref. 2:p. 23] 

A decentralized architecture does not rely on tight 
coordination. It is basically organized as a hierarchy similar 
to the military chain of command (i.e., tasks are delegated at 
lower levels). As noted in the Eastport Study: 

No system part within such a hierarchy needs to 


depend on millisecond-by-millisecond detailed 
instructions from a higher authority. " [Ref. 2:p. 23] 
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CENTRALIZED BATTLE MANAGEMENT 
ARCHITECTURE 


Sensors 









Weapons Weapons 


Global 
Battle 


Manager 


Sensors Sensors 


Figure 4.1 


In the decentralized system, processors are separated 
(physically), individual memory spaces are allocated and data 
communication rates are decreased. These characteristics are 
also known as important parts of a distributed system. The 
system follows the loosely coupled concept. Each battle 
Manager reports (when necessary) to the battle manager at the 
next higher level. For instance, given three levels, the 
lowest level would be considered the local battle manager 
performing fighting functions. The next level would be the 
regional battle managers. They would be responsible for 


targets passing between battle spaces and resolving 
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contentions for resources among local battle managers. The top 
level manager would be the global battle manager. The primary 
job would be to establish strategies for the regional and 


local battle managers. They would also provide the man-machine 





interface for the system. Figure 4.2 depicts a typical 


decentralized architecture. (Ref. 2:p. 45] 
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The following elements are critical advantages attributed 
to a decentralized architecture capable of independent action. 
This list was taken from a report prepared for the 100th 


Congress by the SDIO in June 1987. The advantages are as 


follows: 





1. Simplicity: A simpler architecture can be produced by 
eliminating "perfect" coordination. This approach 
requires less bandwidth, less latency requirements, 
and reduces scheduling demands that have a profound 
impact on software. 


2. Testability: Elements in a decentralized architecture 
act independently. In this regard, each element can be 
tested separately allowing the developer to see how 
the whole system functions in reference to its 
individual parts. 


3. Evolvability: Since decentralized architectures use 
relatively simple interfaces, addition of similar 
elements is far less tedious. Existing computing 
requirements will not be affected by additional 
changes. Scalability in deployment must be supported. 
With every asset that is deployed, the performance of 
the system is improved incrementally. 


4. Robustness: Error and fault tolerance levels in one 
platform are controlled under that particular battle 
manager. Thus, when failures occur at one level, other 
levels are not affected. 


5. Diversity: Robustness is reinforced through diversity. 
Plans for strategic defense must employ the services 
of vendors as well as implement new technologies as 
they evolve. The major driver behind a battle 
management system being diverse is its ability to add 
competition to the procurement market. The result is 
lower system costs. 


6. Durability/Survivability: A decentralized architecture 
is more survivable against countermeasures, and fault 
tolerances are much lower. This results from the 
unlikelihood of errors to propagate throughout the 
entire system. 

The decentralized architecture has been recommended by the 
Eastport Study Group for the design and development of battle 
management software. [Ref. 17:pp. 6-8] 

A third type of architecture is known as a layered 


architecture. This architecture is very similar to the 


decentralized version (i.e., Global and Local battle 


42 











managers). The layered model can have fewer or more layers 
depending on the particular system architecture or the tactics 
employed to counter the ballistic missile attack. For example, 
requirements and strategies may differ from layer to layer by 
using specific weapons, sensors, and operating in different 
conditions. (Ref. 9:pg. 12-20} 

The basic functions for the decentralized and layer models 
are the same. Local battle management functions include 
tracking and classifying targets and allocating proper 
resources. Global battle management functions provide real 
time surveillance, establish rules of engagement, delegate 
resources, provide mutual defense, and perform situation 
assessment. Figure 4.3 provides a view of the layered model of 


battle management. [Ref. 9:p. 12-20] 


C. THE NEED FOR A DEDICATED NATIONAL TEST BED 

Testing and Evaluation (T&E) of any major weapon system 
development is critical to its success or failure. T&E of 
software for strategic defense systems is no exception. It is 
expected to be both difficult and critical. Authorities agree 
that in order to support design and development efforts, a 
national test bed had to be developed. In 1986, Danny Cohen, 
Chairman of the Eastport Study Group, wrote a memo on the 
National Test Bed (NTB). Dr. Cohen stated that the single 
central component of the NTB should be simulation. The 


simulation requirements are numerous and diverse but the two 
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main areas for the application of the simulation are design 


and testing. Simulation’s role is paramount because it is 


impossible to do real time testing on all weapons and sensors. 


Two basic technical questions that simulation should provide 


the answer to are: 1) Can BM/C3 software provide an adequate 


level of reliability and 2) Can the BM/C3 software strategies 


handle the diversity of attacks. These questions can not be 


answered without the extensive use of a National Test Facility 


(NTF). 


Concept definition and preliminary design study of the NTB 


started in March 1986. Martin Marietta and _ Rockwell 
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International were selected to complete the preliminary design 
concept. Martin Marietta subsequently won the contract for 
development for the NTB. Completion of the National Test 
Facility (NTF) is scheduled for FY90. [Ref. 3:p. 5.2-15] 
Figure 4.4 shows the proposed version of the NTB. The 
purpose of the NTB is to evaluate systems and new technologies 
for SDI. Its mission includes demonstrating the feasibility of 
SDSs through computer simulations, evaluation of the 
applicability and feasibility of new technologies, and 


conducting experiments on SDS systems. 
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This test facility will not only be used for software 
testing, but for testing communication assets also. [Ref. 2:p. 


29] According to the DoD Software Master Plan (Preliminary 


Draft): 


“The NTB will inter-connect Army, Navy, Air Force, 
National Laboratories, and Test/Demonstrations facilities 
into a distributed network. The NTB may be thought of as 
a network of resources with the National Test Facility 
(NTF) as its harbor central facility. This composite 
provides the principal resources dedicated to develop 
and/or support experimentations and provide analysis 
support. The NTB is a Natural Resource which draws 
together contractors, the military, government agencies, 


academia and others studying SDS issues. (Ref. 18:p. A- 
13} 
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The National Test Facility will serve as the hub for the 
NTB and will be located at the Falcon Air Station, 20 miles 
east of Colorado Springs, Colorado. 

The National Test Facility, NTB, consists of a set of 
software and hardware tools that support design and 
development, and execution/analysis of simulation experiments 
related to SDI and other associated DoD programs. These tools 
provide support for end-to-end simulation of weapons, sensors, 
communication systems, and C2 systems. Testing facilities will 
also be operated at different locations and will be connected 
to the NTF via communication/computer links. Facilities 
connected to the NTF will include, Vandenburg Air Force Base 
(VAFB), Kirtland Air Force Base (KAFB), and White Sands 
National Laboratory (WSNL). [Ref. 3:p. 5.2-14] 

Additionally, in 1988 a Software Center (SC) was developed 
in order to provide scientists and engineers with efficient 
development tools. This center will establish software policy 
as well as invest in development. The major purpose of the 
center is to provide trusted software tools that reduce risk 
by allowing each component to capitalize on the investment in 
the total software environment. The next section will give the 
reader a fresh understanding of the mission of the Strategic 


Defense System Software Center. [Ref. 3:p. 5.2-15] 
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D. THE STRATEGIC DEFENSE SYSTEM SOFTWARE CENTER 

Hardware/software integration and testing will be 
expensive. Current technology may not be reliable and fast 
enough to handle SDS functions. As stated earlier, the SDS 
Software Center was proposed as a much needed operation with 
the National Test Facility. Its primary mission will be to 
ensure that development, production, integration and 
validation of trusted SDS software through Full Scale 
Development (FSD) is done efficiently. The National 
Aeronautics and Space Adminstration (NASA), Ada Joint 
Programming Office (AJPO), and other SDIO directorates will 
coordinate software efforts to avoid duplication and keep cost 
at a minimum. The Software center will provide help in 
addressing critical software development areas such as 
trustworthiness, configuration management, reusability, 
interoperability, training, technology, and many others. [{Ref. 
18:p. al4] 

Listed below are six basic functions of the software 
center: 

1. Programmatic support for government and contractor 
developers. This team of experts will assist program 
managers and government/contractor developers with 
problems unique to their projects. 

2. Produce and integrate high quality, reliable software 
for SDS systems. This process is critical to the 
success of the SDS mission. 

3. Provide state-of-the-art technology for software 


enyineering eénvironments (SEE) and configuratior 
management system components. 
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4. Establish and maintain a library of reusable Ada 
components. Ada will be the language of choice for the 
NTB-developed software. The NTF also has an Ada 
software development facility. 

5. Ensure consistency of acquisition, design, 
development, integration, and testing efforts through 
software education and training. Training will be 
provided in all phases of software development. The 
goal will be to produce an Ada competent development 
ccmmunity. 

6. Assist in the development and tailoring of new and 
existing standards. Support will be provided to 
organizations such as IEEE, ANSI, and Ada9x. [Ref. 
18:p. A14-15] 

SDIO is providing every necessary means to reduce risk in 
all BM/C3 systems that are software driven. Everyone realizes 
that exhaustive testing of software tools is not practical, 
therefore more emphasis must be placed on the development of 
sound tools for the SDI program. The Software Center will 
provide that development environment. 

If the functions and procedures of the SDS software center 
are properly executed, research and development for strategic 
defense software will be able to reach the majority of its 
goals. [Ref. 18:p. al5] During the 1990 IEEE Conference for 
Strategic Software Systems held in Huntsville, Alabama, Lt. 
Col. Chuck Lillie discussed the short and long term goals for 


the software center. The goals are as follows: 


1. Supportability, compatibility and interoperability of 
SDS mission critical software 


2. Evaluate and demonstrate tools, capabilities, and 


procedures required to implement SDIO policies 
governing SDS software development 
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3. Reduction of the time between SDS _ research, 
development, production, deployment and operation 


4. Efficient production of trusted, high confidence 
software throughout the SDS life cycle 


5. Effective dissemination of Multi-service research 
results through program technology insertion 


6. Compatibility between services and SDS software 
engineering and Ada policies [Ref. 11]. 


There is no question concerning the necessity for the SDS 
software center. In order for SDIO to gain the necessary 
confidence to deploy reliable, trustworthy systems, one must 
first develop those tools to help accomplish this vital 


mission. 
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V. SUMMARY OF THE SDI SOFTWARE DEBATES 


A. INTRODUCTION 

In the previous chapters, several views of whether it is 
feasible to produce reliable and trustworthy software for a 
BM\C3 battle management system were addressed. Along with 
determining the reliability of the software, opinions are also 
expressed on the type of BM/C3 architecture necessary for 
further development of battle management schemes. Finally, the 
guestion of how we test our development was also addressed 
with several feasible approaches, including the development of 
the National Test Bed (NTB). From these debates, the following 
summary chart, Figure 5.1, was developed to highlight the 
position of each proponent and opponent of the software 
debates. Figure 5.1 provides the reader with a brief narrative 


of the positions of each individual discussed in this thesis. 


B. EVALUATION OF THE SDI SUMMARY CHART 

As stated in the introduction of this thesis, the purpose 
was to provide the reader with a framework for understanding 
the software debates. The framework included understanding the 
software complexities (i.e., reliability, availability, and 


testability of numerous weapons and sensors simultaneously) 


and understanding how to apply the corporate knowledge of all 








Techaclegy 
Assessment 


Soleman 
Bushdbaum 


Dr. 


Charles 
Zraket 


The 
Fletcher 
Study 


Dr. 
Frederick 


Breeks 


SO! software can be rettabdle 
and swustworthy ealy ¥ off 
the accessary requirements 
are met: - 

PROBLEM: We deat know 

whet the system is suppose 
to de....Catestrephia failure 


There ts a0 reliable wey to 
demonstrate thet BMD soft- 
ware operate properly whea 
firat wsed. 

The concept of MTBF has 
historically hed Mastied ane 


for critical software systems. 


The anmber of ervors created 
depends on the type of sofi- 
ware, the size of the system, 
ead other factors. There will 
be errors, but how de ve 

prevent catastvephic fellure? 


There wil be errera, but fer 
programe thet are eyetom 
erttical, reseurese are alte- 
cated te enaure ther quelity 
(Le. orrere « @.1 per 1000 
tinee) 


Asking whether there'll be 
errera le the wreng queetien. 
The right quection '- wheth- 
or the tetel BM/C3 systen 
cen be robust and resilient 
in an changing, errer prone 
environment. Anewor.... Yea 


Te essese the feasibility of 
creating and meintaining 

rellebie eeftwere, ene must 
dletinguieh between the un- 
certainties and flawe. {l.a. 
Trystwerthinese ef epers- 

tional design and telerence. 


The panel recommended thet 
more emphasia be placed on 
preceescr developments and 
fautt-telerent designe thet 
wit ensure rellebite epere 
then. 


Two guccesstul techniques 
for eesessing reHabdility end 
truetworthinese ere anetyt 
cat (mathemetica!l preete) 
and eompericel testing. 


SDI SOFTWARE 


SUMMARY 


We ena't expees any safer 
breakthrough ta solve this 
|prodien. Seftwere tchae- 
'fogy tage far bebiad hard- 
were schaolegy and soft- 
ware eagineertag ‘tools may 
mot be the enswer. 


Availability figures are 
useful whes the conditions 
wader which they were 
measured ase well kueva. 
Rzwagelation eutside these 
conditions ts risky. 


mejor breakthroughs. 


Although 8D1 to a complex 
and ditticutt tak, & be- 
deoves the UB. te de re 
search te determine wheth- 


eoftware development envi- 
renament wil be 2 diftiouR 
task. The envbenment must 


The US. should soasider 
three questions sencerning 
SDI softwere development: 
What &@ the asture of the 
BMD system, What ere the 
obstactes, and ean the 


ebstectes be cirenmvented 


f ese ne reasen why | er any 
ether competent, experience. 
od, betier software man 
than LL. could net undertake 
te bud euch « eystea. 


CHART 


Deccavrelised architecture 
suppers the SDI project, 
but i can't be expected to 
solve elf of the battle 
menagemsat problems. 


Battie management archi- 


becturee a3 y 


claimed advantages 
disadvantages to be 
tuely evaluated. 


Gtatribated system 
Seftwere re- 
quirements, algorithms, sad 
destgas aced to be worked 
ean together. 


The Olstrinvied erchitec- 
ture appreech compart. 
mentatizes crucial tune- 
ene in modules se well ce 
individuel syesteme. 


Decentralized architecture 


time and wertime opera 
thene. 


Veo legical battle 
manegement etructure thet 
weuld eansiet of a singie 
bettie maneger replicated 
eoveral times on different 
plettorme 


Globe! bettie management 

eystem would ssesce the 

extent and nelure ef an at- 
tech in progrece and speci 
the rutee of engagement fer 
each ter. (le. Beet, post. 
beest, midcouse, terminal) 





Figure 5.1 





TESTABILITY 


The softwere can never be 
tested fully prior to ancloer 

Simaledeas eoaly provide 
mear veel-me” cesnlts. Tens- 
ing must be done astag the 
“acteal” code. 


Confidence ta the depeudedit- 


ity of « BMD gaem has to by 
derived from simeleted bet- 
thes end wst daring peecetins. 





Test sempenente in actual 
environment with simuisted 
data. Use @ decentralised 
architecture. Wake the soft. 


ware pertionadle te sliew 


Leveie ef seftwere testing 

should inchide: 

1, Reeserch 7 
2.Syetem/eubeysiom teeging | 

3. Syotem-fevel simulatics 


@ reciiatie simulation 
enavirenment . 


Teeting reel time seftware 
often introduces more solt- 
ware errera when @ “Tix” is 
implemented 








individuals involved with the software aspect of SDI. The 
Summary chart is divided into two sections; those who oppose 
and those who support the SDI software efforts. The general 
consensus is that software for SDI is possible, but there are 
a number of problem areas that are plaguing the system now, 
and other problem areas that cannot be eliminated. Because the 
so called impossible has been made possible many times before, 
no one is willing to say that software for SDI cannot be 
developed. 
1. Reliability and Trustworthiness 

Dr. David Parnas, Ware Myers, and the Office of 
Technology Assessment all support the fact that the software 
cannot be assured of not failing catastrophically and that a 
lack of specific requirements for software operations alters 
the development process. It should be noted that even though 
Dr. Parnas has had many negative things to say about SDI’s 
success, he did not state that the software could not ever 
work reliably. He simply stated that the software requirements 
must be understood. Scientists and engineers may not know all 
the necessary requirements for an effective battle management 
System, but the author believes that extensive use of the 
National Test Facility, and other related agencies may prove 
to be the focal point in understanding the requirements. 

2. Availability 
The availability of most systems is determined by the 


amount of time the system operates between failures. In basic 


53 








engineering, this is known as the mean time between failures 
(MTBF). The big question in this area is whether the software 
can be developed with present technology with minimal 
failures. Dr. Danny Cohen took a firm stand on the advancement 
of software technology. Dr. Cohen feels that no major 
breakthroughs are necessary and that today’s software 
technology can be used to create a system with high MTBFs. Dr. 
Parnas stated that the dependence on new technological 
breakthroughs should not be expected to solve the availability 
problem, mainly because of the fact that hardware technology 
is years ahead of the state-of-the-art of software technology. 
In analyzing the debates, it was interesting to find that Dr. 
Frederick Brooks once supported the ideas of Dr. Parnas, but 
later joined sides with Dr. Cohen after testifying at a 
subcommittee meeting on Strategic and Theater Nuclear Forces. 

In essence, the proponents suggested that required 
software availability was achievable, but that more research 
and development efforts were needed. Although not in full 
support of the way availability is assessed, the Office of 
Technology Assessment (OTA) stated that the conditions for 
using availability figures must be well known to be useful. 

3. BM/C3 Architecture 

In Chapter IV, one of the issues that both proponents 
and opponents of SDI agreed upon was the need for a specific 
battle management architecture. It should be noted that no one 


particular architecture was chosen but the structure for the 
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architecture must be in place prior to development. Most 


reports submitted to congress for review recommend that a 
decentralized architecture be used in support of command and 
control of the battle management system. The decentralized 
structure includes loose coupling on various’ system 
components. In contrast, OTA stated that all BM/C3 
architectures as proposed were not specific enough for their 
claimed advantages and disadvantages. Again, the consensus is 
that structure must be in place prior to development. 
4. Testability 

Everyone agreed that the software for SDI will not be 
perfect. There are numerous ways to simulate the actual 
operation of the software, but full-scale testing cannot be 
accomplished prior to nuclear war. Dr. C. A. Zraket stated 
that testing efforts must proceed from research to deployment 
using systematic methods at each level. Simulation is the key 
factor that will determine the effectiveness of the software 
during the actual battle. The testing issue was given the most 
recognition by both the critics and supporters. Comments on 
how the testing efforts should be conducted did not have the 
negative air that other subject areas had faced. One of the 
most weighted concerns came from Herbert Lin. His concern was 
implementing more errors while trying to “fix" old ones. 
Again, this was not a statement saying that testing efforts 
would be useless, rather a caution to those correcting errors 


during the testing phase. 
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The summary chart provides the reader with an overview 
of the major issues that both parties were analyzing. The 
intent of this chart was not to draw conclusions, but rather 
to highlight some of the pros and cons of software development 


for a dependable ballistic missile defense system. 
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VI. DEVELOPMENTAL CONCERNS AND TRADEOFFS 
ASSOCIATED WITH SDI SOFTWARE 
A. INTRODUCTION 

The purpose of this chapter is to focus on some of the 
vital developmental concerns and tradeoffs that may alter or 
hinder the progress of developing an effective BMD system. In 
Chapter II, the role of software for a BMD system was 
discussed. From that discussion important areas that either 
need more research, or solutions that are available that need 
to be implemented were identified. Some of these concerns were 
addressed at the third International IEEE Software Conference 
for Strategic Systems in Huntsville, Alabama, February 27-28, 
1990. Other concerns and tradeoffs have been discussed among 
the proponents and critics over the past five years. 

Among the issues addressed are: 1) The software challenges 
from the SDIO perspective, 2) the use of software engineering 
tools for SDI development, 3) the simulation and testing 
methods available, and 4) the security of SDI software. 

This list of issues and concerns is not exclusive. Because 
of the dynamic nature of the SDI program, it may be that an 


exhaustive list of concerns can never be attained. 
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B. SDIO SOFTWARE CHALLENGES 

The SDIO views the current problems associated with 
development of quality military software to be both real and 
urgent. The plan is to adopt a strategy to promote a change of 
attitudes, policies, and practices concerning software 
acquisition. The strategy has to begin early within the 
acquisition phase in order to control the resources associated 
with software development for strategic defense. Software for 
strategic defense, in particular SDI, faces some monumental 
challenges that must be overcome prior to the development of 
the last phase. At the third International Conference on 
Software for Strategic Systems, Lt. Col. Chuck Lillie 
discussed some of the challenges that SDIO is dealing with. He 
listed them as: 

1. Large Amount of Code 


2. Integration of Software Development by Many 
Contractors 


3. Evaluation and Configuration Management 
4. Coordination of Distributed Assets 


5. Complex Data Fusion, Discrimination, and Tracking 
Algorithms 


6. Parallel and Distributed Architectures for Real-Time 
Performance 


7. Secure, Fault Tolerance Performance 
8. Testing and Simulations [Ref. 11] 
The list of challenges does not include other important 


software issues such as software engineering environments, and 


58 








unambiguous, testable, and traceable specifications. As if it 


has not been stated enough, software development for SDI is 
the most complex task ever faced by DoD. According to a 
computer resource working group, size estimates for phase one 
are huge. Figure 6.1 shows a breakdown of the number of lines 
of source code per system element for the phase I 
architecture. These figures are based on the 1988 
architecture sent to the Defense Acquisition Board (DAB) by 
General Electric. (Ref. 11]} 

The size of the software is not the only challenge that 
SDIO is facing. For example, there are 12 prime contractors 
involved in the phase I development process. There are even 
more subcontractors. Therefore, integration of these elements 
to operate successfully in one environment will be a 
monumental task. As one author stated they should build 
software like they build cathedrals; build them, then pray a 
lot. The more integrated elements that are involved, the 
stronger the emphasis that should be placed on building good 
prototypes. These prototypes should assist in the development 
of requirements, validate size estimates, provide early 
demonstration of the software's performance, and address the 
critical elements involved. Dr. Frederick Brooks said it best, 
“Build a little, test a little, and learn a lot." 

The Aerospace Corporation did a study on the "military 
software problem" during the early 1980s. In that study they 


explained some of the "“causes" of software problems. Two 
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problems in particular that apply directly to SDI’s software 
are management and personnel. The study showed that managers 
lack some necessary skills to “manage” the software process on 
an end-to-end basis. For instance, software managers (program 
Managers) had a poor understanding of the technical 
complexities involved (i.e., hardware selected prior to 
allocation of resources required, lack of communication and 
organization, and lack of life cycle perspective). Brigadier 
General John Vanboise, in his keynote address at the software 
conference, stated that their biggest problems are managerial 
not technical. This issue was also a concern to both the 
Defense Science Board and the Eastport Study Group. General 
Vamboise used a familiar proverb to identify a peculiar 
criteria that all program managers must have a vision. For 
where there is no vision, the people perish. (Ref. 11] 

The second part of the software problem involves people. 
The Aerospace Study pointed out that DoD does not take the 
systems approach to the availability of human resources. There 
is a shortage of skilled programmers. Inevitably this leads to 
using inexperienced personnel. Since the average duty 
assignment for military personnel is about two years, the 
turnover is very rapid. This lack f continuity eventually 
leads to stripping ongoing projects to staff new ones. 

In order to six this personnel problem, more emphasis 
should be placed on personnel receiving a competent education 


in software design and development. For example, Ada is the 
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standard DoD language for software development, but only 15% 
of the colleges in the U.S. teach Ada as a programming 
language. Future resources must come through the formal 
education process. 

In addition to defining some of the challenges for SDI, Lt. 
Col. Lillie also defined their software policy. The purpose of 
this policy will be to require and promote the use of software 
engineering approaches for the development and support of all 
SDS Full Scale Development (FSD) software. Also, the policy 
should be implemented through the various military services 
using individual implementation plans. The key to the concept 
will be consistency factor. Figure 6.2 shows the application 
and scope of the SDS software policy. The Office of the 
Secretary of Defense (OSD) has directed that the SDIO will 
comply with DoD directives 3405.1, 3405.2, and 5000.3 along 
with MIL-STD-1815A. The directives basically inform the SDIO 
of the requirements for software development. Since Ada has 
become the standard programming language for DoD, MIL-STD- 


1815A is the standard Ada specification. 


C. THE USE OF SOFTWARE ENGINEERING TOOLS 

FOR SDI SOFTWARE DEVELOPMENT 

The acquisition process for major weapon system normally 
consists of four phases which are separated by decision 
milestones. The phases are the Concept Definition Phase, 


Demonstration and Validation Phase, Full Scale Development 
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Phase, and Production Deployment Phase. This process is 
initiated when a need is perceived in a particular mission 
area. Basically, the need may arise from a change in threat, 
technology advancements, cost reduction opportunities, or a 
projected obsolescence of existing systems. [Ref. 19:p. 1-13] 
The software development life cycle follows a_ similar 
procedure. First, a feasibility analysis is completed, then 
the requirements and specifications are completed. Continuing, 
the software analyst begins to draw up the design from the 


specifications and actual coding of the software is done. 
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Finally, to see if reliable, dependable results are available, 
extensive testing is begun. After this phase, the initial 
development life cycle is complete. Fig. 6.3 shows 
Similarities between the acquisition phases for a weapon 
system ana the development life cycle concept for software. 

This whole process for software development has evolved 
around ae relatively new technology called software 
engineering. According to an OTA report, the term "software 
engineering" arrived on the scene in 1968. It was the result 
of computer scientists focusing on the difficulties in 
developing complicated software systems. How is software 
engineering defined? Ask any five software engineers this 
question and you’re bound to get at least three, related, but 
different answers. Author Richard Fairley, in his book, 
“Software Engineering Concepts," stated: 

Software engineering is the technological and 
managerial discipline concerned with systematic 
production and maintenance of software products that are 
developed and modified on time and within cost estimates. 
(Ref. 20:p. 2] 

The Institute of Electrical and Electronic Engineers (IEEE) 
expanded this definition to include maintenance and retirement 
of the software. Referring to Figure 6.3, one can see that the 
software life cycle does not stop when the development phase 
is complete. 

Many proponents of SDI tend to think that software 


engineering tools will enhance the software in terms of 


reliability, maintainability, and availability. Th e "tools" 
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are in the form of automated support that may consist of one 
or more programs. On the other hand, critics believe that 
software engineering tools for SDI provide no greater support 
or advantages than any of the previous software tools. [Ref. 
21] The following discussion will focus on "additional" 
paradigms within the software life cycle. Some of these 
techniques are associated with risk assessment and incremental 
development while others make an attempt to eliminate or 
reduce the number of steps within the software life cycle. 
Specifically, we will discuss the possible uses and 
limitations of object oriented programming, automatic 
programming, and artificial intelligence. 

Object-Oriented Programming will allow the properties of 
procedures and data to be combined together. Unlike other data 
structures, an object data structure contains the properties 
of reusability and encapsulation. In essence, the variables of 
the objects are contained within themselves. This process 
allows data transferring of vast quantities of information on 
a function to function basis. Although this is just one 
variation of the term object programming, it is the most 
relevant to SDI; mainly because formal requirements and design 
specifications are used. These were just two of the techniques 
suggested by Dr. Parnas after spending several years on the 
Navy's Software Cost Reduction (SCR) project. The one downfall 


associated with this technique was that using the above 
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stated methods had not lead to reliable code that met the 
Space and time constraints. [Ref. 21] 

It was stated earlier that one of the purposes of using 
software engineering tools was to eliminate or reduce some of 
the requirements and design phases. One method developed to 
employ those techniques is automatic programming. With this 
technique the programmer is literally taken away and becomes 
a "specification writer". In other words, the programmers 
would write the specification for the software and the 
computer would generate the program. Dr. Parnas stated that 
the automatic programming concept was not more than a 
"euphemism" for programming with a higher level language, but 
even the use of improved languages has led to some improvement 
in reliability. In essence, if one can write “trusted” 
software specifications, automatic programming techniques are 
a definite plus. [Ref. 21] 

Finally, how does artificial intelligence (AI) help or will 
it help us to build better BM/C3 software? There has 
certainly been a lot of progress in the AI field recently. In 
March 1989, the American Association for Artificial 
Intelligence (AAAI) held its first annual conference on 
innovative applications of AI. There were about 30 different 
creative applications ranging from expert systems for 
investing to music composition. These applications were using 
computers to solve problems by applying some form of human 


intelligence. [Ref. 22:p. 13] 


67 








Dr. Parnas stated that there are two very different 
definitions of AI in use today. He referred to them as A-1 and 
A-2. By definition, they are as follows: 


AI-1: The use of computers to solve problems that 
previously could only be solved by applying human 
intelligence. 

AI-2: The use of specific set of programming 
techniques known as heuristic or rule-based programming. 
In this approach human experts are studied to determine 
what heuristics or rules of thumb they use in solving 
problems. Usually they are asked for their rules. These 
rules are then encoded as input to a program that 
attempts to behave in accordance with them. In other 
words, the program is designed to solve a problem the way 
that humans seem to solve it. [Ref. 23] 


Even though there has been tremendous work done in AI, most 
potential applications of AI should be handled on a problem- 
by-problem basis. Unfortunately, the SDI battle management 
problem is not an attractive situation at present. According 
to the OTA, AI-1 and AI-2 should not be applied to SDI battle 
management problems until a specific set of battle management 
problems and their solutions are specified. In his ccnclusion 
of AI and SDI, Dr. Parnas stated: 

Artificial Intelligence has the same relation to 
intelligence as artificial flowers have to flowers. From 
a distance they may appear alike, but when closely 
examined they are quite different. I don’t think that we 
can learn much about one by studying the other. AI offers 
no magic technology to solve our problems. Heuristic 
techniques do not yield systems that one can trust (Ref. 
234 

The author believes that software engineering tools have a 
lot to offer the programming world, but one must be mindful of 


tools and techniques that appear to be immediate problem 


solvers. Many software tools may work perfectly on smaller- 
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scale systems, but may lack the same efficiency and 
productivity when applied to larger systems. 

There are many software engineering tools available. The 
key is finding the correct tools that apply specifically to 
the needs of the SDI software efforts. Further improvements in 
Object-Oriented Programming will continue to strengthen our 
confidence in software reuse, thus the development of 
reliable, trusted software to meet space and time requirements 
can become a reality. Any technique that can improve the 
reliability of the software must, at least, be considered 
before it is rejected. As stated earlier, the Strategic 
Defense Software Center will be the hub for testing and 
validating trusted software and must be used to the fullest 
extent. Before Automatic Programming is rejected based on its 
similarities with other high level languages, the technique 
for using this tool must be evaluated. Finally, even though 
Artificial Intelligence has made tremendous advances in the 
last two to three years, one must first find ways to 
incorporate AI into SDI. Specifically, the problems that AI 


must solve must be understood. 


D. THE SIMULATION AND TESTING METHODS AVAILABLE 

Throughout this thesis our focus has been on some of the 
concerns for SDI software. Questions such as will the software 
be reliable, what are the roles of software, and can the 


software be developed free of catastrophic errors, have 
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already been addressed. These are questions that cannot, 





technically, be answered prior to some type of evaluation of 
the software. Two of the primary means of carrying out this 
evaluation is through simulation and testing. 

There are several tradeoffs and concerns that greatly 
affect SDI in these areas. Both the Eastport Study and the 
1988 Office of Technology Assessment report on simulation and 
testing, identify numerous areas for additional research and 
the need to find alternative testing methods. Other recently 
published literature provides further insight on improving 
Simulation and testing techniques. Although these methods do 
not apply specifically to SDI, they do provide the latest 
technology changes and advancements. This section will give 
the reader a brief overview of what simulation and testing 
entails in addition to providing possible insights into areas 
that need further development. 

It is the author’s opinion that evolving technology has 
been a major driver behind the need for increased simulation. 
In the simplest terms, simulation is a system that duplicates 
the behavior of another. The problem occurs when the simulator 
cannot reproduce all the behavioral characteristics of the 
target or the system being duplicated. In the early 1970s 
simulations were primarily based on single engagement models. 
In case of a ballistic missile defense, that meant trying to 
Simulate one missile attacking one target. In the late 1980s, 


the simulation models had to simulate thousands of missiles on 
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multiple targets. The simulation process included anticipating 
the threat, developing a realistic environment to operate 
within, and testing the functions of the model that was 
developed. These same problems plague the environment for an 
effective BM/C3 system for SDI. [Ref. 4:p. 51] 

The simulation efforts are presently geographically 
distributed among several facilities (e.g., The Air Force 
Electronics Systems Division (ESD) at Hanscom Air Force Base, 
Massachusetts, the Army Strategic Defense Command (ASDC) in 
Alabama, and the National Test Facility (NTF) in Colorado). 
One major concern hindering the simulation and testing efforts 
is a lack of interfacing between facilities. In essence, the 
Simulation efforts should employ the work of several 
facilities. Specifically, the Eastport report stated: 

"Simulation efforts should cooperate closely with 
activities at the National Test Bed (NTB). But for 
several reasons, NTB should not be the only simulation 
facility. First, simulation is too vital to the strategic 
defense effort to permit a “monopoly” that would be 
implied by such a single implementation. Second, 
comparison of results from different simulation 
facilities, for purposes of cross-verification and 
validation is essential. Third, a centralized 
implementation at NTB would likely lead to 
classification, very limited access, and narrow focus, 
which would curtail the simulators’ erfectiveness and 
prevent it from producing confidence in the system’s 
functional ability and reliability. [Ref. 2:p. 31] 

The more simulators interface with other systems, the more 
trust one may be able to put in the system. The Eastport 


Study referred to three classes of levels for simulation 


operations. Low level simulations would be used for sensor and 
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weapon development, mid-level simulations for interfacing with 


other on-line systems, and high-level simulators for studying 
and evaluating BM/C3 strategies. With this concept working 
effectively, testing efforts may show considerable 
improvement. 

Simulating the functions of an SDS is a phenomenal task. 
This is especially true when algorithms for tracking, 
discrimination, weapons control and guidance are involved. Dr. 
zZraket stated that the designs of these algorithms must be 
tested on an end-to-end basis. He also stated that testing 
should be done using actual code rather than emulating their 
behavior through the use of simulators. The problem here is 
unequivocal; no one knows what the performance of the 
algorithms will be. This leads to the conclusion that credible 
Simulations are needed. For example, simulations are needed to 
predict the position of a track based on the details of the 
estimated present position. This need led SDIO to initiate the 
National Test Bed. Zraket further stated that two capabilities 
must be developed: 1) a model-evaluation process to establish 
the credibility of models and simulations and 2) an 
experiment-design process to foster systematic and informative 
experiments. The capabilities are greatly needed because most 
current SDS simulations lack fidelity, high resolution, and 


the actual code for SDS algorithms and BM/C3. The formulation 


of a systems-oriented software engineering environment is 














needed to integrate the development and evaluation of SDS on 
an end-to-end basis. [Ref. 25:p. 96] 

In order to simulate a target and formulate some type of 
model, one must first make an assessment of the environment 
and the equipment involved. When simulations are done without 
known qualities of the environment and other factors, the 
accuracy of the simulation lacks quality. This may very well 
be the major or the most treacherous concern facing simulation 
experts. How does one model a Soviet decoy or missile if there 
is no physical access to them? According to an OTA report, 
simulation experts from the Naval Research Laboratory stated 
that building simulations without prior access to "real" 
equipment caused many unexpected surprises. Even if there was 
access to performance characteristics, the problems would not 
be solved. Simulators may not be able to reproduce the 
parameters and different signatures of events such as nuclear 
explosions. This means that accuracy and realism involved in 
the simulations would be further diminished. [Ref. 12:p. 206) 

The Department of Defense (DoD) is constantly looking for 
new ways to combat the complex challenges of modelling and 
simulating the performance of major weapon systems. According 
to Mr. James H. Atkinson, Test and Evaluation (T&E) 
specialist, modelling and simulation (M&S) can offer the 
potential for overcoming the existing testing limitations of 
weapon systems. He stated that a generic baseline methodology 


could be used by different developers of weapon systems to 
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tailor a performance evaluation program to the specific 
weapon. [Ref. 25:pp. 143-146] This author believes that this 
is a concept that can be applied to the development of battle 
management software. The concept involves initiating four 
basic characteristics that must occur throughout the software 
development cycle. The clé acteristics are 1) Degree of 
Representation - defining the limits of M&S process; 2) 
Practicality - obtaining useful output from the M&S process; 
3) Validation - establishing acceptance and credibility with 
the M&S process and 4) Configuration Control - tracking of 
updates/modifications in the M&S process. Using these four 
characteristics could possibly help establish a good "working" 
baseline for understanding and modelling software for SDI. 
Figure 6.4 shows three domains of test and evaluation that can 
be applied to the software development life cycles. This 
figure is a mock up version used for the weapons systems 
development life cycle. The basic functions and relative 
application are the same. The process does not eliminate the 
need for thorough testing of the system, but could help to 
produce better testing results. [Ref. 25:p. 143-146] 

One of the issues not discussed in the modelling process 
was cost. There is no doubt that money could be a driving 
force for this project. One possible tradeoff is that more 
money could be placed up front to institute the modelling and 
Simulation process. This would possibly result in reduced 


costs for validation testing. With emphasis being placed on 
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accelerating the development process, the models and 






Simulators are needed to increase the effectiveness of the 





software. 






E. SECURITY FOR SDI 


Security is an issue that plagues many "Sensitive" projects 






whether it’s DoD related or exclusive to the private sector. 






Over the last 10 years there has been a growing increase in 







the number of attack. on computers and communication networks. 


The attackers are not choosy and they don’t have “respect of 










network or computer." [Ref. 26] Because of the critical 








functions of the BM/C3 networks and computers, greater 












emphasis should be placed on securing the assets for SDI. The 






sad part is that the means of security go far beyond locking : 





the door at night. Therefore, in this section the author will 






focus on some of the failures of security that are applicable 









to BM/C3 computers. 


In 1987, the SDIO submitted an interim assessment of SDI’s 






computing requirements to the 100th Congress. In that report, 













the SDIO stated that minimizing the complexity in the concept 
design of SDS was the key to fault tolerance and security with 
respect to software. This is true especially when the end 
product results in a slow, expensive system. In other words, 
security and fault tolerance need to be integrated during the . 
design phase. By now, the results of "adding" requirements to 


a system are well known. The study also indicated that the 
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security policies for the SDS must reflect the highly 
decentralized nature of the system. Decentralization does not 
solve all of our architecture problems, but in this case it 
provides us with consistency. [Ref. 17:p. 10] 

One of the glaring tradeoffs that needs further research is 
the performance of the system. A more secure system also means 
a more complex system. It has been stated in some reports to 
Congress that there is not a need for another study on 
computing requirements. The author disagrees for a number of 
reasons. Mainly, because we have not scratched the surface on 
items such as security mechanisms for strategic defense 
systems. 

Computer security for SDI should be based on two separate 
aspects; technological and applicational. By technological, 
we can address security from logical and physical points of 
view. Logically, security is the protection of data and access 
or gateways between programs. Physical security is the action 
that can be taken to prevent physical harm to the resources. 
[Ref. 26:p. 433] 

Applicational computer security addresses the development 
of new applications and the maintenance of those applications. 
Both the technological and applicational approach to computer 
security can be applied te the SDI security policy. In the 
previous section we looked at how to do modelling and 
simulation with the software development life cycle. Computer 


security specialists, K.P. Badenhorst and Jan H.P. Eloff, 
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developed an "ideal methodology" for computer security in view 
of the typical structured approach to the software development 
life cycle. They structured the major phases as introduction, 
implementation, and maintenance. Figure 6.5 shows the layout 
of each phase within the methodology and description of each 


phase is listed below: 


High Level View of a Methodology 
for 
Computer Security 
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Figure 6.5 


1. Phase 1: Initiation - Requires management to establish 
awareness and support. Also a special group of people 
should focus on securing the assets by introducing new 
techniques. 


2. Phase 2: Establish Computer Security Policy - Again, 
top management (Program managers) must establish a 
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“corporate” policy for security in order to develop 
good management controls. 


3. Phase 3: Risk Analysis and Project Definition - This 
is where cost factors can be decreased by ensuring 
that proper security measures have been selected. 


4. Phase 4: Installation - Covers technological aspects 
such as logical access, physical access, encryption, 
and other methods. 


5. Phase 5: Maintenance/Ongoing - Full development of 
controls for applicational systems. [Ref. 26:pp. 443- 
435) 


These phases or a model similar to this should be considered 
when employing security tactics. 

Security is important because the bulk of SDI‘s resources 
rely on communication networks and computers. Whenever a 
computer system or a communication network is violated there 
are a variety of losses involved. Those losses include the 
loss of goods and services, the loss of assets, and the denial 
of computer services. [Ref. 29] These services are critical 
because of the time factor that would be involved in a nuclear 
war. The probability of bringing an entire network of 
computers back on-line after a failure during a nuclear war is 
almost impossible. It does not matter whether the method of 
destruction was accidental or deliberate, the consequences are 
the same. Much consideration should be given to finding ways 
of avoiding situations like the “worm" created by computer 
hacker, Robert T. Morris. A worm is a type of instruction that 
is placed in computer program causing incorrect results when 
the program is run. No physical access is required since these 


“worms” can be placed in the programs through the use of 
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floppy diskettes, internal/external file transfers, and by 
having unauthorized access to computer networks. According to 
an article in Computer World, Morris gained access to 
computers at the National Aeronautics and Space 
Administration’s Ames Research Center in California, the U.S. 
Air Force Logistics Command in Ohio, the University of 
California at Berkeley, and Purdue University in Indiana. 
These were just a few of the facilities where Morris was able 
to get in and cause considerable damage. [Ref. 27:p. 1] 
Computer security fails often because people have a narrow 
minded view of security as being only physical in nature. To 
eliminate some of the failures one must understand the 
targeting concepts, the motives for attacking computer 
systems, and how to uncover the penetrator. It’s not always 
the "enemy" that’s plaguing our systems. [Ref. 29] Morris and 
other computer hackers proved that point. In a previous 
research report on computer security, the author stated that 
there were three basic approaches to a system’s defense. They 
include: 1) dispersion, 2) duplication, and 3) defense in 
depth. In the event of accidental or deliberate threats, 
dispersion is a tactic used to minimize the losses. Since 
total destruction of a computer system would require multiple 
attacks, dispersed systems are less susceptible to a total 
system shutdown. SDI’s decentralized architecture would employ 
the use of the dispersion technique with its BM/C3 operations. 


Secondly, duplication or redundancy must be maintained in 
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order to enhance the life of the system. Duplication is the 


method of providing back-up components for enhancing fault 
tolerance. Finally, defense in depth would include the use of 
an alarm system, a response system and a recovery system. The 
alarm system’s function will be to detect a threat in time to 
either avert it or minimize the damage. The response system 
must apprehend the villain and neutralize the effect of the 
error or accident. The recovery system must repair the damage 
and restore system operation. Obviously these functions alone 
do not merit full protection against "“hackers", but 
collectively they help form a defensive ring. [Ref. 29] 

The Computer Security Act of 1987 and the Computer Fraud 
and Abuse Act of 1986 are pieces of legislature for punishing 
individuals who willfully attack government resources. This is 
not the real problem. Today, there is no quantitative way to 
measure the amount of security in a system, but DoD has 
developed a standard for evaluating the security for computer 
systems. DoD Standard 5200.28 is the Department of Defense 
Trusted Computer System Evaluation Criteria. The concept used 
in this standard consists of matching the features of a system 


against those known to be necessary to provide security. 
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VII. CONCLUSIONS 


Software development for the Strategic Defense Initiative 
(SDI) is one of the most complex tasks that both government 
and def-nse contractors have ever faced. Why is this 
development effort so hard? Mainly because of the changing 
requirements associated with the SDI program. Even in the 
midst of writing this thesis, information that was once a "hot 
item" is just another passing term in the huge SDI vocabulary. 
To some extent, this constant change in requirements is good 
because it shows that technology is rapidly progressing. On 
the contrary, the analysts and computer scientists that are 
trying to develop reliable, dependable, and trustworthy 
software for these systems are facing a "“programmer’s 
nightmare." Another problem is that state-of-the-art software 
technology is still lagging far behind hardware technology. 
Although there has been vast improvements in software 
technology, one may still ponder the question of whether or 
not these improvements can support the operational task of 
SDI. 

The software debates held at Stanford University and the 
University of California at Los Angeles were not just “another 
conference” for scientists and engineers to argue over ideas. 


The debates brought out important issues, some of which are 
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discussed in this thesis, that were necessary for the 
successful design and development of the SDI software and 
battle management/C3 system. It is obvious that all the issues 
from the debates are not yet resolved, but research and 
development efforts should continue until acceptable solutions 
are found. 

The software for SDI will be responsible for coordinating 
a conglomeration of weapons and sensors. It will take over 20 
million lines of code to complete this task. Will the software 
make the Ballistic Missile Defense (BMD) system and the Battle 
Management/C3 system reliable? This is the question that 
engineers and computer scientists alike are pondering on a 
daily basis. The research and development programs must remain 
in high gear in order to allow an answer to this question with 
any confidence. It’s a known fact that one will not know the 
answer to this question until war is started. It is the 
consensus of all involved with SDI that the point of war 
remains distant. Much consideration must be given to the wise 
words of Dr. Frederick Brooks, "Build a little, test a little 
and learn a lot." This is exactly the route that software 
development for SDI must take. The establishment of the 
National Test Bed (NTB), National Test Facility (NTF) and the 
Strategic Defense Software Center in Colorado Springs, 
Colorado is very timely in support of testing and evaluation 
efforts for SDI. This certainly should not be the only 


facility testing SDI components. Other agencies should be 
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involved, therefore, providing a comparative analysis of the 
system's operational capabilities under several conditions. 

Obviously, there are many other factors that software 
developers must consider. For example, the choice of Battle 
management architecture effects the structure and development 
of the software. The decentralized battle management 
architecture has been the choice of most agencies that have 
completed studies for the SDIO. Decentralization does not 
resolve all of the SDI related issues, but it best suits the 
needs for the current software development efforts. 

Advanced software engineering tools have made _ very 
impressive improvements in the areas of "expert systems" and 
"decision-support" systems. These tools are certain to have an 
impact on SDI in future development efforts. Special caution 
must be taken if proponents of SDI plan to depend on these 
tools for the development of SDI software. Tools that do not 
allow the software to remain in "discrete" states must be 
avoided. Dr. David Parnas says that they should avoid using 
artificial intelligence and automatic programming techniques 
for program verification. On the contrary, one should not 
eliminate any possible development tools and techniques until 
they can be proven "unreliable." Full scale tests are 
impossible and every one is willing to accept that fact, but 
improvements in the simulation efforts may shed new light on 


some of the once unresolvable problems. 
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Finally, the software is pivotal for strategic defense. It 
is possible to develop the software, but the following issues 
must be understood: 1) understand the complete function of 
the software at all levels and 2) accept the fact that it will 
not be error-free. The job of the engineers and computer 


scientists is huge; keeping the system from failing 


“catastrophically." 
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